QRZ! Ham Radio 5/QRZ Ham Radio Callsign Database - Volume 5.iso/digests/tcp/940231.txt

Internet Message Format | 1994-11-13 | 11.1 KB

Date: Mon, 17 Oct 94 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: List
Subject: TCP-Group Digest V94 #231
To: tcp-group-digest


TCP-Group Digest            Mon, 17 Oct 94       Volume 94 : Issue  231

Today's Topics:
                         Fix for KA9Q/Jnos??
                             JNOS Timers
                           SCC.C - various
                         TCP Retry Time [fwd]

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 17 Oct 1994 01:00:24 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: Fix for KA9Q/Jnos??

Does anyone have the fix for JNOS or KA9Q that causes it to crash when
it receives millions of little packets? For example, I can crash Jnos
at will by doing a flood ping: ping -f jnosbox. I know this was
discussed recently, and someone had a fix for it.


---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
[e-mail] [e-mail] [e-mail]
---------------------------------------------------------------------------

------------------------------

Date: Sun, 16 Oct 1994 07:09:24 -0600 (MDT)
From: Klarsen <[e-mail]>
Subject: JNOS Timers

    This weekend ka5oyo Bill Dupree and I decided to look at a vexing
problem we encountered. We are both running jnos110G compiled by
ourselves to meet our needs.

    Since Bill lives in Deming NM he has no free access to the
internet and has relied on my putting new and wonderful things in my
/public for him to get using ftp.

    The problem was this. We are connected thru a X1J node I put up
so our connects are full tcp carried by AX.25. When there is no other
activity we could get a data rate of about 20 bytes/sec. But if there is
ANY interferance the rate drops to under 10 bytes/sec.

    It seems that the jnos timers were incapable of coping with a
missed packet. That started me looking in the WONDERFUL!!!! cmnshelp.zip
files I put up in nos for timers. I found the first one in the ax25 section.

    AX25 has a timer called ax25 maxwait. When set to zero it is not
functional. The DEFAULT setting is zero. So I set ax25 maxwait to 30000
(30 seconds) and we experimented. That sure helped when things were busy!
But it wasen't a full fix. We looked for other timers.

    There is a TCP maxwait too! It is exactly the same function as
the ax25 timer. And the default setting is zero. This means if the tcp
server ever misses a packet it just waits forever for that packet! So we
set TCP maxwait to 30000 and then WOW! When another user is busy nos
backs off and lets him do his thing. But if there is a 30 second period
of quiet, nos takes off again and tries to get back in business. It sure
looks good from all aspects.

    The bottom line is: put this in your autoexec.nos file:

ax25 maxwait 30000
tcp maxwait 30000

    I am sure you will notice a differance and the fun of ftp will
return. We are not done. There are almost for sure more timers in nos
that we have not found that are important and at default zero settings.
So if you find anything that looks bad please put it out.

-karl k5di

------------------------------

Date: Mon, 17 Oct 94 10:32:22 BST
From: [e-mail]
Subject: SCC.C - various

A couple of points regarding SCC.C:

Firstly, one of my locals found that doing a "detach <scc port>"
causes NOS to trash both channels on the SCC chip concerned.

The fix for this involves modifying scc_stop():

-----------8<-----------------8<-----------------

/* de-activate SCC channel */
static int
scc_stop(ifp)
struct iface *ifp;
{
    struct sccchan *scc = Sccchan[ifp->dev];
    int i_state, d, dum = 1;

    i_state = dirps();

    VOID(RDREG(scc->ctrl));             /* make sure pointer is written */
>>  or(scc,R9,(ifp->dev % 2) ? CHRB : CHRA );   /* reset the channel */

>>  for (d = 0; d < 1000; d++)  /* wait - needs 5 PCLK cycles before next SCC access */
>>      dum *= 10;

    switch(ifp->type){
        case CL_SERIAL_LINE:
        case CL_KISS:
            free(scc->fifo.buf);
        default:
            break;
    }
    free(scc);
    Sccchan[ifp->dev] = NULLCHAN;
    restore(i_state);
    return 0;
}

-----------8<-----------------8<-----------------

(I'm not sure if the wait loop is the right sort of timing - but it's copied
 from the Hardware Reset done earlier in the code).



Secondly, there has been discussion about open-squelch operation. I currently use
a BayComm USCC card above the G8BPQ switch. However last week I had an experiment
at getting SCC.C to operate with open-squelch.

The following are my "first-cut" mods - but there is room for improvement:

1/. In scc_sdlc(), change:

    if (Sccinfo.hwtype & HWBAYCOM){        /* BayCom-USCC card? */
        wr(scc,R15,BRKIE|DCDIE);        /* enable ABORT, DCD interrupts */
    } else {
        wr(scc,R15,BRKIE|CTSIE|DCDIE);  /* enable ABORT, CTS & DCD interrupts */
    }

to:

    if (Sccinfo.hwtype & HWBAYCOM){        /* BayCom-USCC card? */
        wr(scc,R15,BRKIE);    /* 941012 Don't want DCD any more */
        /* wr(scc,R15,BRKIE|DCDIE); */        /* enable ABORT, DCD interrupts */
    } else {
        wr(scc,R15,BRKIE|CTSIE|DCDIE);  /* enable ABORT, CTS & DCD interrupts */
    }

i.e. so DCD changes no longer cause an interrupt.


2/. Immediately after the above code, change:

    if(RDREG(scc->ctrl) & DCD){    /* DCD is now ON */
        if (!scc->extclock)
            WRSCC(scc->ctrl,R14,SEARCH|scc->wreg[R14]); /* DPLL: enter search mode */
        or(scc,R3,ENT_HM|RxENABLE);    /* enable the receiver, hunt mode */
    }
to:
    if (!scc->extclock)
        WRSCC(scc->ctrl,R14,SEARCH|scc->wreg[R14]); /* DPLL: enter search mode */
    or(scc,R3,ENT_HM|RxENABLE);    /* enable the receiver, hunt mode */

i.e. enable rx.


3/.  in scctimer(), change:
                    if(scc->a.fulldup == 0){
                        Random = 21 * Random + 53;
                        if(scc->status & DCD || scc->a.persist < Random){
                            /* defer transmission again. check for limit */
defer_it:                        if(--(scc->a.maxdefer) == 0){

to:
                    if(scc->a.fulldup == 0){
                        Random = 21 * Random + 53;
                        if(!(scc->status & SYNC_HUNT) || scc->a.persist < Random) {
                            /* defer transmission again. check for limit */
defer_it:                        if(--(scc->a.maxdefer) == 0){

i.e check SYNC_HUNT, not DCD.


4/. A little later in scctimer(), change:

            if((scc2 = Sccchan[i]) != NULLCHAN &&
              scc2 != scc &&
              uchar(scc2->group) & uchar(scc->group) &&
              ((scc->group & TXGROUP && scc2->wreg[R5] & RTS) ||
              (scc->group & RXGROUP && (scc2->status & DCD)))){                        goto defer_it;
            }
to:
            if((scc2 = Sccchan[i]) != NULLCHAN &&
              scc2 != scc &&
              uchar(scc2->group) & uchar(scc->group) &&
              ((scc->group & TXGROUP && scc2->wreg[R5] & RTS) ||
              (scc->group & RXGROUP && !(scc2->status & SYNC_HUNT)))){
                goto defer_it;
            }

i.e. check SYNC_HUNT, not DCD.



Thirdly, has anyone had any experience of using a Zilog 85230 on an SCC card, as a
plug in replacement for a 8530 ?


Andrew Benham
----------------------------------------------------------------
[e-mail]   BNR Europe Ltd, London Road, Harlow,
                           Essex CM17 9NA
                         [phone]    Fax: [phone]
Home:                    [e-mail] [44.131.181.17]
----------------------------------------------------------------

------------------------------

Date: 16 Oct 94 14:57:00 PST
From: "UCLA::CORBIN" <[e-mail]>
Subject: TCP Retry Time [fwd]

*******The following is a forward for Mike, wd6ehr

===============================================================
Subject: Re: TCP retry time
In message <[e-mail]> [e-mail]
(D. Crompton) writes:

> The REAL answer to this has always been FIX the problem - that is the
> bad path. Really bad circuits will always be a problem. Setting the
> retry mechanism to overcome this is the wrong way and will
> ultimately hurt others on the circuit who do have good connection.
> We typically have not put enough effort into our RF paths but rather
> want some quick SW fix for our hardware problems.

I have had EXCELLENT paths to other tcp/ip stations and still ended up backed
off into eternity, back in the dark ages when we ran NET and only had
exponential backoff.  Large ftp's were virtually a pipedream - and we didn't
have ftp resume back then, either! (Yet another problem fixed in software :-)
Channel congestion is a fact of life in many locations.  Retries and fixing
things in software are a fact of life in the big city.

Many of our bands are plagued with incredible levels of QRM, for many reasons.
These days, with the de facto "no theory" test, many amateurs are electronic
imbeciles (pragmatic observation, not criticism) who "know the answers" but
don't understand the questions: "'Too much splatter, set your deviation', you
say?  I'm not a deviant - I'm happily married!"  "What do you mean I can't run
more than one rig on the same band at the same site without cavities and
circulators?  It works fine - I've done it on packet for years!"

Both of these problems are "fixed" with "retry 0" and other sledge hammer
methods.  However, they generate lots of QRM for the rest of us, and certainly
compound channel congestion.

We're also plagued with QRM from other services, i.e. radar on 440, etc.  In
fact, the only non-shared VHF plus bands we have are 2 meters and 222 mHz, and
both of these are jam-packed solid in Southern California.

Besides, MANY hardware problems are fixed in software these days.  Oftentimes,
it is much simpler and more practical to do so.  However, I agree that jamming
the channel with a zillion retries by stations running "oinker mode" (i.e.
persist 255), or other "brute force" methods, is not "fixing" a problem.

What we need is something that will actually "fix" problems.  Most rejected
packets have small errors.  Some type of damaged packet recovery system would
go a long way toward improving our paths.  Something like Reed-Solomon error
correction, that adds redundant information to allow damage to be repaired,
would be good.  If we use this, it would make sense to disable it until
needed, i.e. when retries are detected.  Another possibility is some form of
memory ARQ, where we save damaged packets and try to reassemble these into
good ones.  With the computers most of us have these days, and the fact that
even 486's are under $500, I don't think processor power is an issue :-)

As long as we expect "perfect packets" in a very imperfect RF world, we're
going to have problems.

 73, Mike Curtis wd6ehr

------------------------------

End of TCP-Group Digest V94 #231
******************************